NASA Technical Memorandum 103899 


52JW.D 


//v-oy- 

//& o~73 




Design and Evaluation of an 
Advanced Air-Ground Data-Link 
System for Air Traffic Control 

Wim den Braven 


( NAS A-T M- 103899 ) DESIGN AND N92-33407 

EVALUATION OF AN AOVANCEO 
AIR-GROUND DATA-LINK SYSTEM FOR AIR 
TRAFFIC CONTROL (NASA) 40 p Unclas 


G3/04 0118073 


j 

January 1992 


NASA 

National Aeronautics and 
Space Administration 


NASA Technical Memorandum 103899 


Design and Evaluation of an 
Advanced Air-Ground Data-Link 
System for Air Traffic Control 

Wim den Braven, Ames Research Center, Moffett Field, California 


January 1992 


NASA 

National Aeronautics and 
Space Administration 

Ames Research Center 

Moffett Field, California 94035-1000 





Table of Contents 


ORIGINAL C0BIAKS 




5 f.'rf-Vf' 


Acronyms 

Summary 

1. Introduction 

2. Data-Link Concept . 

2.1 Data-Link Communication 

2.2 Center/TRACON Automation System 

2.3 Data-Link Integration in CTAS 

3. Data-Link Protocol 

3.1 Data-Link Complementing Voice 

3.2 Data-Link Message Formats 

3.3 Data-Link Dialogues 

4. Data-Link/Controller Interaction 

4.1 Design Guidelines 

4.2 Data-Link/Controller Interface 

4.3 Data-Link Applications 

4.4 CTAS/Data-Link Synergism 

4.5 Example of Data-Link Communication 

5. Experimental Evaluation 

5.1 Experiment Description 

5.2 Analysis of Recorded Data 

5.3 Analysis of Questionnaires 

5.4 Experimenter Observations 1 

6. Conclusions 

References 

Tables 

Figures 

Appendix. Description of Data-Link Message Types and Formats 


Page 

....v 

....1 

....2 

....2 

....2 

....3 

....4 

....4 

....5 

....6 

....6 

....6 

....8 

....9 

..10 

..11 

..11 

..12 

..15 

..16 

..17 

..17 

..18 

..20 

..33 


PRECEDING PAGE BLANK NOT FILMED 


t I 




Acronyms 


ATC 

air traffic control 

cm 

communications manager 

CTAS 

Center/TRACON Automation System 

DA 

Descent Advisor 

DCP 

data-link control panel 

DHP 

data-link history panel 

DNP 

data-link numeric panel 

DSP 

data-link status panel 

ETA 

estimated time of arrival 

FAST 

Final Approach Spacing Tool 

FL 

flight level 

id 

identity 

KIAS 

knots indicated airspeed 

LAN 

Local Area Network 


MF 

metering fix 

PAS 

Pseudo-Aircraft System 

PSCN 

Program Support Communications 
Network 

pvd 

planview display 

RNAV 

area navigation 

SSR 

secondary surveillance radar 

STA 

scheduled time of arrival 

TMA 

Traffic Management Advisor 

TRACON 

terminal radar control 

TSRV 

Transport Systems Research Vehicle 

VHF 

very high frequency 

WC 

waypoint capture 

4D 

four dimensional 


For abbreviations concerning data-link applications, see table 1. 
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Design and Evaluation of an Advanced Air-Ground Data-Link System for 

Air Traffic Control 

WIM DEN BRAVEN* 

Ames Research Center 


Summary 

The design and evaluation of the ground-based portion of 
an air-ground data-link system for air traffic control 
(ATC) are described. The system was developed to 
support the 4D Aircraft/ATC Integration Study, a joint 
simulation experiment conducted at NASA’s Ames and 
Langley Research Centers. The experiment focused on 
airborne and ground-based procedures for handling air- 
craft equipped with a 4D-Flight Management System 
(FMS) and the system requirements needed to ensure 
conflict-free traffic flow. The Center/TRACON 
Automation System (CTAS) at Ames was used for the 
ATC part of the experiment, and the 4D-FMS-equipped 
aircraft was simulated by the Transport Systems Research 
Vehicle (TSRV) simulator at Langley. The data-link 
system supported not only conventional ATC communica- 
tions, but also the communications needed to accommo- 
date the 4D-FMS capabilities of advanced aircraft. Of 
great significance was the synergism gained from integrat- 
ing the data link with CTAS. Information transmitted via 
the data link was used to improve the monitoring and 
analysis capability of CTAS without increasing controller 
input workload. Conversely, CTAS was used to anticipate 
and create prototype messages, thus reducing the work- 
load associated with the manual creation of data-link 
messages. 

1. Introduction 

An air-ground data link is expected to play an increasingly 
important role in air traffic control (ATC). Not only will it 
improve the exchange of information between air traffic 
controllers and pilots, but it will also allow for integration 
of aircraft and ATC system capabilities. In May 1991 the 
4D Aircraft/ATC Integration Study was performed to 
investigate such air-ground integration issues. This study, 
a joint simulation experiment of NASA’s Ames and 
Langley Research Centers, focused on airborne and 
ground-based procedures for handling aircraft equipped 
with a 4D Flight Management System (FMS) and the 
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system requirements needed to ensure a conflict-free 
traffic flow. The scenarios that were investigated 
considered arrival traffic in Center airspace, from en route 
cruise until handoff to the TRACON. For the ATC part of 
the experiment the Center/TRACON Automation System 
(CTAS) at Ames was used. The 4D-FMS-equipped 
aircraft was simulated by the Transport Systems Research 
Vehicle (TSRV) simulator at Langley. A data-link system 
was developed to allow the exchange of digital data 
between the simulated aircraft and ATC. 

The need for a data-link capability was already indicated 
by a previous experiment on air-ground integration, 
performed in July 1989 (refs. 1 and 2). Datalinking has 
the potential to increase the efficiency and clarity of air- 
ground communications, and in addition will allow 
communication of the minimum data the ground system 
needs to analyze an aircraft’s preferred trajectory and to 
check for potential conflicts. Thus, for the 1991 experi- 
ment, an air-ground data-link system was developed that 
would support not only conventional 1 ATC communica- 
tions, but also the communications needed to accommo- 
date the 4D-FMS capabilities of advanced aircraft. 
However, the experiment did not involve all the elements 
of an operational air-ground data-link system. It was 
assumed that an air-ground data-link network, based, for 
example, on VHF-radio, satellite, or secondary surveil- 
lance radar (SSR) mode S, will be developed that provides 
the means to actually transmit messages. In this case the 
focus was on those elements of the air-ground data-link 
system that are related to the message contents, rather 
than to the actual transmission of the messages. In addi- 
tion, none of the characteristic performance parameters of 
a real data-link system, such as communication capacity 
limitations, communication delays, and reliability were 
modeled. These parameters are assumed to be unrelated to 
the message content, and therefore less relevant for this 
experiment. 

The purpose of this report is to describe the design and 
evaluation of the ground-based portion of the air-ground 


^‘Conventional” refers to currently used message types and 
dialogues, as opposed to potential ones. It does not refer to the 
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data-link system, as developed for the 4D Aircraft/ATC 
Integration Study. The main requirements for its design 
were that it should (1) support conventional ATC com- 
munications and also the communications needed to 
accommodate the 4D-FMS capabilities of advanced air- 
craft; (2) be acceptable for controllers; and (3) have the 
potential for easy change and evolutionary development. 

Although several small-scale experiments were performed 
during the development process, the real acceptance test 
was the experiment performed for the 4D Aircraft/ATC 
Integration Study. A description of the results of that 
experiment constitutes a major portion of this report. 

The structure of this report is as follows. The overall data- 
link concept is described in section 2, which also includes 
a brief description of CTAS, in which the data link has 
been integrated. The data-link protocol, specifying the 
general rules, formats, and procedures for data-link com- 
munications, are described in section 3. This is followed 
in section 4 by a detailed description of the data-link 
design in terms of the data-link/controller interface, data- 
link applications, and CTAS/data-link synergism. Sec- 
tion 5 gives an overview of the setup and execution of the 
experiment and presents a description and analysis of the 
results. Finally, in section 6 some general conclusions are 
drawn, and recommendations for future study and 
development are made. 

2. Data-Link Concept 

Two important technological improvements in the 
present-day situation are prerequisites for integration of 
aircraft and ATC systems: improved automation of 
ground systems, and an air-ground data link. In this 
experiment, which focused on the aircraft/ ATC integra- 
tion, the improved automation was provided by CTAS, 
the Center/TRACON Automation System, under devel- 
opment at Ames. The ground-side of the data link was 
developed as an integrated part of CTAS, thereby taking 
advantage of the advanced capabilities of that system. 

This section discusses some aspects of the general data- 
link concept, on which the data-link design was based. 

The basic elements of the data-link communication chain 
are discussed, an overview of CTAS is given, and a 
general description of how the data-link system was 
integrated into CTAS is presented. 

2.1 Data-Link Communication 

A data link is a means of transferring digital data between 
two or more end-users. An end-user is any function or 
process (not a human!) that requires data transfer, for 
example, an arrival planning function that sends a sched- 
uled time of arrival (STA) to an aircraft. An air-ground 


data link enables communication between ground-based 
ATC computer systems and airborne flight systems. 
Through these systems, it also allows communication 
between an air traffic controller and pilots, as with the 
current radio-telephony. For ATC, a data link has many 
potential applications, ranging from sending a simple 
heading instruction to supporting a complex profile 
negotiation process (ref. 3). 

Three generic components can be distinguished in a data- 
link communication chain: the source (sender), the 
medium, and the destination (receiver). 

The source is the end-user that initiates the message 
transmission process. Depending on the message type 
(application), a particular “application process” is invoked 
that will actually send the message. This invocation could 
be a simple software function call, such as 
“send_new_heading_to_aircraft (newjieading, 
aircraftjd).” 

The medium represents the portion of the communication 
chain that provides the actual telecommunication connec- 
tion. The medium may consist of one or more (aeronauti- 
cal) telecommunication (sub)networks. Typically, there is 
a network linking processes within an ATC facility, link- 
ing facilities with aircraft, and linking systems on board 
the aircraft. A facility network is for example a Local 
Area Network (LAN) that connects the various CTAS 
tools (see next section). SITA’s (Soci6t£ Internationale de 
Telecommunications Aeronautiques) Satellite Aircom 
network is an example of an air-ground network. 

The destination is the end-user that receives the message. 
An application process of the end-user uses the message 
to generate the data that will actually enter the receiving 
system. Such an application process can again be seen as 
a simple software function, such as “receive_message,” 
triggered by the reception of a message from the medium. 

Sources and destinations can be specified on different 
levels of detail, varying from a facility name (e.g., Denver 
Center) to the actual software function that has to process 
a message. For this experiment, the global level was used, 
whereby sources and destinations are identified by facility 
names on the ground side and by aircraft call signs on the 
airborne side. 

The remainder of this section describes CTAS, and how 
the data link was integrated in CTAS to provide the 
ground-based source and destination for air-ground data 
communication. 

2.2 Center/TRACON Automation System 

This section gives a brief overview of CTAS, the Center/ 
TRACON Automation System. This system provided the 
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advanced ATC capabilities for the experiment. For a more 
detailed description of the design and operation of CTAS, 
the reader is referred to references 4-6. 

CTAS is an integrated set of automation tools that assist 
air traffic controllers in the efficient management and 
control of arrival traffic. It comprises three complemen- 
tary tools: the Traffic Management Advisor (TMA), the 
Descent Advisor (DA), and the Final Approach Spacing 
Tool (FAST). Communications between these tools, and 
between tools and the “outside world,” go through the 
communications manager (cm). This overall CTAS 
concept is illustrated in figure 1. The system has been 
implemented on a series of workstations, connected by a 
LAN. 

The TMA includes algorithms, a graphical interface, and 
interactive tools for use by Center and TRACON traffic 
managers. It coordinates the traffic flow through the 
feeder gates to the final approach fix and generates land- 
ing and metering fix crossing schedules that minimize 
delays. The TMA broadcasts the schedules, through the 
cm, to all sectors equipped with DA or FAST. It also 
receives information from DA and FAST, such as esti- 
mated times of arrival (ETAs), needed to perform its 
scheduling task. 

FAST assists TRACON controllers in sequencing and 
spacing aircraft onto the final approach path. It gives 
speed and heading advisories which allow the aircraft to 
meet the arrival time as scheduled by the TMA. Since the 
experiment focused on Center arrivals, FAST was not 
used for this experiment and will not be mentioned 
further. 

The principal function of the DA is to assist Center 
arrival/descent controllers in accurately and efficiently 
controlling arrival traffic to the TRACON feeder gates, in 
accordance with the schedules broadcast by the TMA. 

The DA is based on a generic four-dimensional (4D) 
trajectory-generation algorithm, adaptable for different 
types of aircraft. For all arrival flights, the DA periodi- 
cally synthesizes trajectory solutions, based on controller 
inputs, current aircraft state (from radar tracking), and the 
TMA schedule. The DA translates these trajectory solu- 
tions into controller advisories which include speed for 
cruise and descent, the top of descent point, and heading. 
The DA also has algorithms to predict potential future 
conflicts between pairs of aircraft, and a limited conflict- 
resolution capability was added for this experiment to 
solve such conflicts. 

The controller interacts with the trajectory-synthesis, 
conflict-prediction, and conflict-resolution algorithms to 
plan conflict-free trajectories that meet the arrival time. 
Once satisfied with a particular solution for an aircraft, the 


controller can issue the corresponding arrival clearance, 
and switch the DA from the planning mode to the moni- 
toring mode for that aircraft. In this monitoring mode the 
DA compares the actual aircraft trajectory with the last 
calculated solution, in order to determine deviations in the 
lateral and vertical directions and in time. This switching 
from the planning to the monitoring mode is referred to as 
“locking” a trajectory, and is one of many interactive 
functions that can be performed by the controller. 

Figure 2 shows a typical DA planview display (pvd). The 
picture shows the high-altitude sector, as defined for this 
experiment. Besides some overflights, this sector handles 
arrivals from the north-east from en route until handoff to 
the low-altitude sector. Aircraft with green and yellow 
tags on the pvd are arrivals; those with white tags are 
overflights. The blue lines on the map are the arrival 
routes. On the left side of the screen is the so-called time- 
line, which gives information about the schedule for the 
metering fix. The blue tags, on the left side of the time- 
line, give the scheduled time of arrival (STA) for each 
arrival flight, as determined by the TMA. The green tags 
on the right show the estimated times of arrival (ETAs), 
as calculated for each aircraft by the trajectory synthesis 
algorithms. For each aircraft the difference between its 
STA and ETA indicates how well the aircraft is expected 
to meet its schedule. 

The controller can “select” one or more aircraft by click- 
ing on the aircraft symbol, the small diamond shaped 
symbol displayed at the aircraft’s position. The aircraft 
symbol and the aircraft tag turn yellow, and additional 
information is displayed for that aircraft in the rectangular 
panel in the top-middle of the screen. In figure 2, aircraft 
COA213 has been selected by the controller. The timeline 
ETA-tag also turns yellow, and a speed-range bracket is 
shown to indicate the earliest and latest arrival times 
possible with speed control only. The picture also shows 
several data-link panels; these will be described 
extensively in section 4. 

In order to be able to fulfill its specific display and advi- 
sory functions, each CTAS component keeps information 
on the aircraft in the airspace under consideration. In 
general, this information is referred to as the (CTAS, DA, 
TMA, or cm) aircraft data base. This data base plays an 
important role in the integration of the data link in CTAS, 
which is outlined in the next section. 

23 Data-Link Integration in CTAS 

Under CTAS, each Center sector is equipped with its own 
DA. Each DA keeps an aircraft data base containing all 
the information needed to perform its display and advi- 
sory functions for controlling the aircraft in that sector. 
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Each DA also handles input by and output to the con- 
troller. The cm handles all communications between 
sectors, and between sectors and the outside world (i.e., 
outside the CTAS system boundaries). A similar architec- 
ture was chosen for the ground-based portion of the data 
link: the data-link/controller interface is integrated in the 
DA and the link with outside communication networks is 
integrated in the cm. This architecture allows the use of 
information in the DA aircraft data base to create data- 
link messages, and the update of that data base from 
information sent and received by data link. This syner- 
gism was expected to improve significantly the combined 
operation of the DA and the data link, by the controller. 

With this architecture, the general process of data-link 
communication through CTAS is as follows. For uplink, 
data-link messages are created in the DA, using informa- 
tion from the data base. Upon controller approval, a 
message is sent from the DA to the cm, and the DA data 
base is updated based on the information in the message. 
In the cm, the message is coded in the proper format for 
transmission and subsequently transmitted over the 
appropriate medium. For downlink, messages are received 
in the cm and decoded into an internal format. The cm 
does not have information on which sector(s) should 
process a message; therefore, it broadcasts each decoded 
message to all sectors. Based on specific rules, each sector 
determines whether a message should be processed or not, 
and subsequently processes or discards the message. 

The coding and decoding of messages in the cm is neces- 
sary because data-link messages are handled internally (in 
CTAS) in a specific format. In general, this format is not 
suitable for transmission to the destination. Therefore, for 
messages to be uplinked, the CTAS format has to be 
coded into a transmission format, and downlinked mes- 
sages received in the cm have to be decoded. This coding 
and de-coding in the cm makes it easy to adapt for differ- 
ent applications, transmission media, or destinations. 

In summary, the following data-link functions were 
integrated into the DA 

1 . Display data-link information to the controller 

2. Handle controller inputs 

3. Retrieve information from the aircraft data base 

4. Update the aircraft data base 

5. Send/receive data-link messages to/from the cm 

and the following data-link functions were integrated into 
the cm 

1 . Code messages for uplink 

2. Decode downlinked messages 


3. Send/receive messages to/from the DAs 

4. Send/receive messages to/from the outside world 

Data-link integration in the cm will not be discussed 
further. The implementation of the data link within the 
DA will be described in detail in section 4. First, the data- 
link protocol is described in the next section. 

3. Data-Link Protocol 

The data-link protocol is the set of rules, data formats, and 
conventions that determines the way data-communication 
takes place between elements in the communication chain. 
For example, it specifies how to use the data link as a 
complement to voice, and how dialogues between aircraft 
and ATC are structured. This section describes several 
aspects of the data-link protocol, as developed for operat- 
ing the data link in the context of this experiment. 

3.1 Data-Link Complementing Voice 

For the design of the data link, a complementary protocol 
(ref. 7) for controller-pilot communications was adopted, 
wherein data link was used as the primary medium for 
selected applications and voice for others. The range of 
data-link applications was selected such that for standard 
situations, arrival traffic could be controlled entirely by 
datalinking. However, for each message to be sent, the 
controller could choose to use either the data link or 
voice. 

A consistent procedure was established for the combined 
use of voice and datalinking under standard and nonstan- 
dard conditions. This procedure demands flight crew 
acknowledgment of all ATC messages, and also that each 
acknowledgment is given over the same medium (voice 
messages should be acknowledged by voice, data-link 
messages by data link). For nonstandard situations, for 
example, when a flight crew cannot comply with an ATC 
instruction, the (negative) acknowledgment has to be 
followed by voice contact to explain the situation and 
expedite its resolution. 

Since this procedure depends on the use of voice for 
communication during resolution of nonstandard situa- 
tions, it is necessary that, upon entry into a new sector, 
each flight establishes two-way radio communications. 
Therefore, the flight crew has to use voice to check into a 
sector. However, it is not necessary to check out by voice: 
the selection of the medium — voice or data link — for 
issuing the frequency-change instruction is at the 
controller’s discretion. The flight crew simply has to 
acknowledge the message by using the same communica- 
tion medium as that used by the controller. 
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An important aspect of using the data link for air-ground 
communications is to determine which controller (sector) 
has jurisdiction over communications with a particular 
aircraft, both for uplink message transmission and for 
downlink message reception. Unlike voice communica- 
tion, the data link is independent of a sector frequency. 
Therefore, there must be a clear and unambiguous rule to 
determine, for each aircraft, the sector with data-link 
communication authority. For this experiment, we based 
the rule on specific information available in the aircraft 
data base of the ATC computer, namely, which controller 
“owns” an aircraft, that is, the controller who last 
accepted control of the aircraft. The rule was that only the 
controller who owned the aircraft, could send data-link 
messages to and receive messages from an aircraft. 

However, on controllers’ request, one clearly defined 
exception was made for sending the “frequency change” 
message to an aircraft (shipping). This message is sent 
after the transfer of control has been accepted by the next 
sector’s controller and the “old” controller still has radio- 
contact with the aircraft, but no longer owns it. 

The procedure for the handoff of an aircraft to the next 
sector is summarized as follows. 

First, the controller-to-controller handoff: 

1 . Ground handoff is initiated by the sector that owns 
the aircraft. The handoff can be initiated by the controller 
by selecting the DA’s “initiate handoff’ menu-option for 
the aircraft under consideration. 

2. New sector accepts the handoff and thus takes over 
“ownership.” The handoff can be accepted by choosing 
the DA’s “accept handoff’ menu-option for that aircraft. 

This is followed by the controller-pilot-controller handoff: 

3. The old sector no longer owns the aircraft. The only 
message it is now allowed to send by data link is a 
change-frequency message. For each aircraft in the hand- 
off process this data-link message can only be sent once. 

4. The response to this message (roger or unable), if 
sent by data link, is processed by both the old and the new 
sector. In the old sector the acknowledgment is used to 
close the communication loop; in the new sector the 
response is used to indicate that there is one-way data-link 
communication with the aircraft, and that the voice check- 
in can be expected. 

5. The new sector should not send any data-link mes- 
sage until the pilot has checked in with the new sector by 
voice . 

Several checks were built into the data-link software to 
ensure that the proper procedures were followed. 


3.2 Data-Link Message Formats 

A data-link message format specifies the structure of the 
information required to process or send a data-link 
message. The minimum information required for data 
exchange between end-users consists of the following 
items: 

1 . Destination id (identity), which determines where the 
message goes 

2. Source id, which determines where a message comes 
from, and thus where the response to a previously 
received message should be sent 

3. Message type, which determines the type and format 
of the information that is in the message text; it is also an 
indication of how the message should be processed 
(which application process) 

4. Message text, which contains the actual information 
(the data) to be sent, specific to the message type 

5. Message id, which allows for unique identification of 
each message; this can be a sequence number which, 
together with the source and destination id, uniquely 
identifies the message 

As already mentioned in section 2.1, source and destina- 
tion identities are given by aircraft call signs and facility 
names. Within a facility, the sector that must process a 
message from a particular aircraft, is determined by the 
aircraft call sign and the rules for data-link communica- 
tion authority, described in the previous section. 

The message text may have more than one version, for 
example, a readable and a coded version. The readable 
version is shown to the controller. The coded version is 
used for internal processing or for transmission. If the 
message text is coded for transmission, it has to be 
decoded at the destination, for display purposes and for 
handling by the receiving system. 

The general structure of both the CTAS message format 
and the format used for transmission to the TSRV is 
shown in figure 3. The CTAS format was primarily 
designed for ease of internal handling of data-link 
messages. The transmission format, developed by NASA 
Langley, is more suitable for transmission and conforms 
to ACARS standards for air-ground data-link 
communication; the appendix contains a more detailed 
description of both formats. 

33 Data-Link Dialogues 

A data-link dialogue specifies the sequence of data-link 
messages that are exchanged for a common purpose. For 
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example, the following elementary dialogue types can be 
distinguished. 

1 . Clearance dialogue , to issue a clearance. This 
dialogue consists of an uplinked clearance, followed by a 
downlinked acknowledgment (roger or unable). 

2. Information dialogue , to send arbitrary information. 
This dialogue consists of an up- or downlinked informa- 
tion message, followed by an acknowledgment of receipt. 

Both dialogue types are illustrated in figure 4, by means 
of time-sequence diagrams. 

Several elementary dialogues can be connected to form 
more complex dialogues. As an example, figure 5 shows 
both the ground-initiated (uplink) and the air-initiated 
(downlink) request-for-information dialogues. The first 
response to a request is a confirmation (roger) or negation 
(unable). A confirmation, which in these dialogue types 
corresponds to the “standby” used in voice communica- 
tion, will be followed by the requested information. 

For this experiment, even more complex dialogues were 
developed for the air-ground profile negotiation process 
and to deliver a complete 4D-trajectory clearance. A 
general description of such dialogues can be found in 
reference 3. 

4. Data-Link/Controller Interaction 

This section discusses the design of the data-link system 
in terms of the data-link/controller interface, the selected 
data-link applications, and the synergism gained from 
integrating the data link with CTAS. All are aspects that 
determine the way the controller interacts with the data 
link. First, some general design guidelines are discussed. 

4.1 Design Guidelines 

The following general guidelines were used for develop- 
ing a data-link system that would be acceptable for 
controllers. 

1 . The controller workload, associated with operating 
the data link for air-ground communication, should be 
kept to a minimum. This was achieved by minimizing the 
number of inputs (mouse button clicks, mouse move- 
ments, and keyboard entries) needed to create and send 
messages. 

2. Workload increase related to data-link communica- 
tions should be compensated by workload reductions for 
other tasks. This was achieved by including an automatic 
update of the aircraft data base, based on the information 
sent by the data link. 


3. The data link should improve the situational aware- 
ness of the controller, certainly not reduce it. This was 
realized by displaying data-link status information, in 
particular of outstanding messages, and by keeping a 
history of the data-link messages sent and received. 

With regard to the creation and monitoring of data-link 
messages, the data-link interface design allowed the 
controller to preview adaptable messages and to review all 
messages transmitted or received. The following guide- 
lines were used for the design. 

1. For adaptable messages, that is, messages that can be 
modified manually, the controller needs to be able to 
preview the message and to approve actual transmission 
of the message. 

2. For nonadaptable messages, the controller does not 
necessarily have to preview the exact contents of the 
message, provided the information to be sent is available 
on the DA traffic display or can be retrieved by the 
controller from the aircraft data base. This is especially 
important for the lengthy and complex messages of the 
profile negotiation process (described in a separate docu- 
ment). However, it should be possible for the controller to 
review afterward what actually has been sent. 

3. For nonadaptable messages, it is also not necessary 
that the controller approve each message that is sent. For 
example, certain messages may be grouped together and 
transmitted by one control action. However, it should be 
possible for the controller to review afterward what 
actually has been sent and when it was sent. 

The next section describes how these guidelines have 
been applied to design the actual data-link/controller 
interface. 

4.2 Data-Link/Controiler Interface 

The basic CTAS system uses advanced graphics and 
windowing techniques for display of information. A 
computer mouse and keyboard are used for input. The 
data-link interface, incorporated in the DA, uses the same 
means and methods for input and output and is completely 
integrated into the DA’s controller interface. Four 
separate display panels are available for the data link. 
These panels are graphical overlay windows that can be 
positioned anywhere on the screen at the controller’s 
discretion. Each panel has its own specific functions and 
features, which will be described later in this section. The 
design allows nearly all inputs to be made by using the 
mouse, that is, by moving the mouse to point at objects 
and clicking the mouse buttons to invoke certain events. 
The keyboard is used for entering ffee-text messages. 
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The data-link interface supports two main data-link 
communication tasks. The first is the invocation of data- 
link messages for uplink, the second is monitoring of 
ongoing data-link communications and dealing with 
replies. The general procedure for invocation of a data- 
link message for uplink comprises five steps: 

1. Selection of one and only one destination (aircraft) by 
the controller 

2. Selection of the application by the controller 

3. Creation, by the data-link software, of a message 
proposal 

4. Completion/adjustment of the message by the 
controller 

5. Initiation, by the controller, of message cancellation 
or transmission 

With the DA, there are three ways to select a destination: 

(1) move the mouse pointer over an aircraft symbol or tag 
(dwelling) and press a specific key on the keyboard; 

(2) use the mouse to bring up an aircraft menu and choose 
the data-link option; and (3) mouse-click on the aircraft 
tag . 

To execute the other steps, two separate panels are 
available, the data-link control panel and the data-link 
numeric panel. 

The data-link control panel (DCP) is used to select the 
data-link application, to view the corresponding message, 
and to actually invoke the transmission or cancel it. 

Figure 6 shows the general layout of the DCP. Its main 
elements are as follows: 

1 . Call-sign field, showing the aircraft to which the next 
message will be sent 

2. Message field, showing the message text that will be 
sent 

3. Send button, which invokes the actual transmission of 
the message (to the cm) 

4. Cancel button, which cancels the process of data-link 
message creation 

5. Application selection buttons, to select the applica- 
tion that will be used. Each button has one or more 
options which can be selected by repeatedly clicking the 
button (see sec. 4.3). 

Furthermore, a pop/stay selection is available on the DCP 
to allow the controller to choose whether the DCP and 
DNP (described next) should stay up after sending a 
message (“stay” option) or that they should disappear 
until the next data-link invocation (“pop” option). 


The data-link numeric panel (DNP) is used to modify 
numerical values in certain message types. It acts as an 
electronic numeric keypad. Figure 7 shows the general 
layout of the DNP. Its main elements are as follows: 

1. Digit buttons 0-9 and a decimal (.) button, to enter 
decimal numbers 

2. Clear button, to erase a decimal number, so that a 
new number may be entered 

3. Increment/scroll up (+) and decrement/scroll down 
(-) buttons, to scroll through the values that are available 
for a specific message type; for example, to scroll through 
the Flight Levels (FLs), with a 10-FL increment below 
FL290 and a 20-FL increment above 

4. Space (“ ”) button, 2 3 4 5 to enter a space prior to entering 
a value 

Two other panels are available to assist the controller in 
monitoring ongoing data-link communication and to deal 
with replies: the data-link status panel and the data-link 
history panel. 

The data-link status panel (DSP) displays a list of active 
messages: uplinked messages awaiting pilot response, 
recently received pilot responses, and other messages 
awaiting controller response. Figure 8 shows the general 
layout of the DSP. For each message there is a 

1. Call-sign field, showing the aircraft that a message 
was sent-to or received-ffom 

2. Message field, showing the message text sent or 
received 

3. Status field, showing the status of the message. The 
available status options are 

“sent,” for a message just sent but not (yet) replied to 

“ROGER,” for a positive acknowledgment of a 
previously uplinked message 

“UNABL ,” for a negative acknowledgment of a 
previously uplinked message 

“rcvd,” for a received downlinked message (not for a 
roger or unable) 

“info,” for a message that presents additional 
information to the controller, for example when a 
downlinked profile cannot be reconstructed 

4. Elapsed time, which shows the time elapsed since the 
last change in message status 


2 This button was not necessary, since the “clear” button clears 
only the value contained in the message text and leaves the 
space that separates a value from the preceding word. 
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5. Remove button (rm), allowing removal of messages 
from the DSP at the controller’s discretion. 

When a profile proposal is received from an aircraft, the 
DSP also shows an enter button (fig. 9), which, if 
selected, tells the DA to use the received profile 
parameters for its trajectory computations. 

The DSP shows up to 10 messages, with the message that 
was sent or received most recently at the bottom. Addi- 
tional messages are not shown until other messages have 
been removed, either manually by the controller or auto- 
matically. For example, messages with “ROGER” or 
“info” status disappear from the DSP automatically after 
30 sec. The limit of 10 messages on the DSP, and the 
30-sec display time, are just two of many data-link design 
parameters that can be easily adapted. 

The data-link history panel (DHP) contains a history of 
all messages sent and received, even after their removal 
from the DSP. This panel can be invoked at the con- 
troller’s discretion, for example, to check whether a 
certain message has already been sent. Figure 10 shows 
the general layout of the DHP. For each message sent or 
received the DHP shows: 

1. The call sign of the aircraft to which the message was 
sent or from which it was received 

2. The sequence number of the message, with a prefix U 
for uplinked and D for downlinked messages 

3. The message text 

For downlinked roger or unable messages the message 
field shows the sequence number of the message to which 
the reply was made (230358 in fig. 9). This sequence 
number allows the controller to correlate downlinked 
acknowledgments to a previously uplinked message. 

The DHP also has a scroll bar which allows the controller 
to scroll through the entire list: different mouse inputs 
allow line-by-line scrolling, page-by-page scrolling, or 
jumping to a specific portion of the list. 

Figure 2 illustrates the controller/data-link interface, 
integrated into the DA display. The picture shows the 
DCP and DNP in the upper right portion of the screen. 

The DSP is shown to the left of these panels. The picture, 
which was taken during one of the traffic scenarios of the 
experiment, also shows several other display features of 
the DA, such as the timeline on the left and the descent 
advisory panel in the upper middle of the screen. A 
general description of DA display features was given in 
section 2.2; a more detailed description can be found in 
reference 4. Note that the DHP is not shown in the figure: 
it is at the controller’s discretion to show this panel. 


43 Data-Link Applications 

A data-link application specifies one particular use of the 
data link. In general, each application corresponds to one 
specific message type. For example, the application for 
issuing a heading instruction sends a heading message. 
However, there are exceptions in which the application 
requires more than one message type. An example is the 
application to issue a 4D arrival clearance, which consists 
of a route clearance message, a 4D arrival clearance 
message, and a profile constraints message (see the 
appendix). 

The data-link applications were selected to enable full 
data-link control of arrival traffic in the Center airspace. 
No effort was made to include non-control messages, such 
as weather information messages. The available applica- 
tions are grouped into the following categories, each with 
its own button on the DCP (fig. 6, from left to right): 

1. Strategic messages (button 1), for the 4D and DA 
arrival clearance and the profile request 

2. Tactical messages (buttons 2-4), with separate 
buttons for the heading, altitude, and speed instructions 

3. Navigation messages (button 5), for the proceed- 
direct-to and route-intercept messages 

4. Frequency-change message (button 6) 

5. Free-text message (button 7). 

The complete list of available applications on the DCP is 
given in table 1. The 4D and REQ types are complex 
applications dealing with the 4D-FMS equipped aircraft. 
The DA-type is a CTAS-specific arrival clearance: it 
corresponds to the descent advisory created by the DA 
(ref. 4), which specifies a top-of-descent and the required 
descent speed profile. The other types have an equivalent 
conventional voice message. 

The full set of available message types, their internally 
used (CTAS) format, and the formats used for transmis- 
sion to the TSRV, are presented in the appendix. The 
appendix also describes messages that were uplinked 
automatically (information, route, and profile messages), 
and the messages available for downlink. 

An important aspect of the design of data-link messages is 
the exact meaning of those messages. Voice messages are 
often a combination of several pieces of information, such 
as “proceed direct to SMITY, resume own navigation.” 
The resume-own-navigation is an essential part of the 
message. For this experiment, a proceed-direct-to 
clearance by data link was defined to include the resume 
command. For those cases for which the resume was not 
valid, the controller had to use voice. However, the 
software is easily adaptable to allow controller selection 
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of appending messages, depending on the initial message 
selected. 

Another example is “turn right 30 degrees, vectors for 
spacing.” In this case the second half of the message gives 
an explanation. The current design gave the controller the 
option to send explanations as a free-text message by data 
link or by voice. The design may also be extended easily 
to include options for appending standardized explanatory 
comments to certain data-link messages. 

4.4 CTAS/Data-Link Synergism 

Major advantages were provided by the integration of the 
data link within CTAS. The information available in the 
DA aircraft data base was used to select and create proto- 
type data-link messages for the controller. Conversely, the 
information sent by data link was used to update that 
aircraft data base. Both ways facilitated a considerable 
reduction of the total number of controller inputs — and 
workload — required for operating both the DA and the 
data link, compared with independent implementation. 

As soon as a data-link message is approved for transmis- 
sion, the aircraft data base is updated. This gives the 
controller immediate feedback on the effect of a message 
on the DA trajectory analysis, as will be described below. 
The consequence of this procedure is that if an unable 
reply is received instead of a roger, the data-base update 
was not appropriate, and the old information in the data 
base must be restored. An alternative solution is to wait 
until a positive response (roger) is received from the pilot. 
This solution was rejected, since in that case the update of 
the aircraft data base lags behind with respect to the 
controller’s actions. 

An example of how the data-link benefits from CTAS is 
as follows. All uplinked data-link messages require that 
one destination (aircraft) is chosen; that the application is 
chosen; and that the message is approved for transmission. 
Without CTAS, this would amount to a minimum of three 
mouse clicks for sending a message by data link. How- 
ever, because of the CTAS/data-link integration, in many 
cases only two clicks are required: upon selecting a desti- 
nation by clicking on the aircraft tag or dwelling on an 
aircraft symbol, the data-link software tries to anticipate 
the application to be used. This educated guess is based 
on the information available in the aircraft data base, 
including information on the current advisories presented 
to the controller. The following simple rules were applied 
(from high to low priority): 

1 . If the aircraft is not owned by the sector (see 
sec. 3.1), select the frequency-change message (VF) 


2. If the DA shows a speed-resolution advisory (to solve 
a potential conflict), select the speed message (SP) 

3. If the DA shows an altitude resolution advisory, 
select the altitude message (AL) 

4. If the aircraft is 4D-FMS equipped: 

If there is a downlinked profile proposal, select the 
profile constraints message (PRO), which is part of the 4D 
arrival clearance application (see appendix) 

Else select the profile request message (REQ) 

5. If the DA shows a cruise-speed advisory for an 
aircraft, select the speed message (SP) 

6. If the profile is locked (sec. 2.2), select the speed 
message (SP) 

7. If the DA shows a descent advisory, select the DA 
arrival clearance message (DA) 

8. Else select the heading message (HE) 

In section 5 it will be shown that these simple rules were 
reasonably effective in anticipating the message type. 

In addition to this automated mechanism for application 
selection, there are several shortcuts available to the 
controller to combine the selection of aircraft and applica- 
tion. For example, when a controller clicks on the altitude 
portion of the aircraft tag (the second line), the altitude 
message will be selected automatically; clicking on the 
speed portion (third line) auto-selects the speed message 
for that aircraft. In addition, when selecting an aircraft by 
use of the aircraft menu, a data-link suboption may be 
chosen to specify the desired application. 

Additional advantages of the CTAS/data-link integration 
are presented below, for each of the application 
categories. 

Strategic messages- When one of these messages is 
selected, the DA will create the message for the 
controller, based on the information available in the data 
base. Under normal circumstances, there is no reason for 
the controller to change the contents of any of these 
messages. When sending a DA or 4D arrival clearance via 
data link, the aircraft trajectory is automatically locked 
(sec. 2.2). If such a clearance was issued by voice, this 
must be done manually, by clicking on the aircraft’s ETA- 
tag on the timeline (fig. 2). 

Tactical messages- In general, the tactical messages HE, 
TRT, TLT, AL, and SP are initialized with the current 
aircraft heading, altitude, or speed, depending on the 
message type chosen. The use of current aircraft state 
information for an initial guess of the desired value in the 
message results in only minor adjustments being 
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necessary to obtain the desired value. There are three 
major cases in which CTAS is used to make a better 
message proposal. First, when the DA calculates a cruise 
speed advisory, the speed message is initially selected, 
with the advised speed in the message. Second, when 
there is a speed or altitude resolution advisory, to resolve 
a predicted conflict, the corresponding message is initially 
selected with the advised value. Third, when the aircraft is 
in the waypoint capture (WC) mode, the target intercept 
heading for waypoint capture is initially selected for the 
heading message. Provided the controller accepts the 
proposed value, the workload associated with message 
creation is significantly reduced (see sec. 5.2). 

An additional effect of sending tactical messages by data 
link is that locked trajectories are automatically unlocked 
(since a tactical clearance has precedence over a strategic 
clearance). Furthermore, a heading message sent via data 
link automatically puts the aircraft in the waypoint capture 
mode to ensure consistent trajectory analysis by the DA. 
An altitude assignment by data link tells the DA to enter 
the assigned altitude in the data block of the aircraft. 

Navigation messages- In order to get proper DA- 
advisories for aircraft in the waypoint capture mode, the 
controller must select one particular “capture waypoint.” 
This is a standard CTAS procedure (ref. 4). If the 
proceed-direct-to (PD) message is selected, the prototype 
message contains the name of that waypoint. No addi- 
tional inputs are needed (although the controller may 
change the name to one of any published waypoint). Like 
the tactical messages, the transmission of a PD message 
via data link unlocks a cleared trajectory and puts the 
aircraft in the waypoint capture mode. For the route- 
intercept (RI) message, the DA fills out the published 
name of the current or the next route segment, depending 
on whether the aircraft is on-route or off-route. 

Frequency-change message- In the current CTAS 
system, the sector to which an aircraft will be handed off 
is determined by the sector number the controller has 
entered in the right field of the DA scratchpad, a two-field 
input area on the traffic display. In figure 2, the scratch- 
pad is shown on the bottom right of the display. For the 
frequency-change (VF) message, that sector number 
(sector 15 in fig. 2), is used to fill out the message with 
the facility name (e.g., Denver), the sector type 
(approach/center), and the frequency used by that sector. 
This is under the assumption that each sector has one 
primary voice frequency. Thus, no additional controller 
inputs are required for this message. 

In the next section, the data-link related results of the 
experiment are discussed. It will be shown that the 
CTAS/data-link integration considerably enhances the 


efficient use of the data link. But before doing so, a data- 
link example is presented. 

4,5 Example of Data-Link Communication 

Using the picture of figure 2 as reference, an example is 
given of how the data link is used by the controller. The 
example starts approximately 1 min before the picture was 
taken and ends about 2 min later. The figure shows 
COA213 on a delay vector. The controller’s intention is to 
slow the aircraft down to 250 knots indicated airspeed 
(KIAS) and bring the aircraft back on route through a 
proceed-direct to SMITY, a waypoint previously selected 
by the controller. 

To send the speed instruction by data link, the controller 
clicks on the third line of COA213’s tag. This brings up 
the DCP and the DNP, in the upper right portion of the 
screen. The controller has positioned the panels there in 
order to avoid overlap with the sector’s airspace. 

The DCP comes up with a speed message proposal, the 
result of clicking on the third line of the tag. When the 
controller selected the aircraft for data link, the DA 
showed a speed advisory of 250 KIAS in the fourth line of 
the aircraft tag of COA213, similar to the advisory shown 
for COA788. As a result, the speed message will already 
contain the target value of 250 KIAS, so the controller 
only has to click on the “send” button to send the mes- 
sage. Had the intent been to send a different value, the 
controller could have used the DNP to change the value 
shown in the speed message. 

When the message is sent, the DCP and DNP will disap- 
pear from the screen, unless the controller has previously 
selected the “stay” option, in the bottom right comer of 
the DCP. In that case the panels will stay on the screen. 

To show the message just sent, the DSP appears (unless it 
is already shown for previously sent messages), showing 
the message with the status indication “sent.” The DSP 
keeps track of the time elapsed since the message was 
sent: 14 sec in figure 2. 

The controller does not have to wait for the pilot to 
respond to the message before sending the next message 
to the same aircraft, or to another aircraft. In this case the 
controller clicks again on the aircraft tag of COA213, on 
the first line this time, and the DCP shows a proposal to 
send the DA arrival clearance. However, the intent is to 
send a proceed-direct instruction, so the controller clicks 
on the navigation button (WPCAP on the DCP) to select 
the corresponding message. The selected button is high- 
lighted, and the computer generates a message proposal: it 
looks for the selected capture waypoint (SMITY) and fills 
out the name in the message, as shown in figure 2. The 
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controller can send the message and it will be added to the 
DSP. 

When the pilot’s response to the speed message is 
received, the status indicator on the DSP will change from 
“sent” to “ROGER” or “UNABL,” to show the pilot’s 
reply. If it was an unable, the pilot is required to contact 
the controller by voice to explain and solve the situation; 
otherwise the transaction is completed. In both cases, after 
taking notice of the pilot’s reply, the controller can 
remove the message from the DSP by clicking on the 
remove (rm) button. 

5. Experimental Evaluation 

5*1 Experiment Description 

Although the data-link system is the subject of this report, 
it was not the main focus of the experiment. The primary 
objective of the experiment was to investigate issues 
regarding the integration of 4D-FMS-equipped aircraft in 
a 4D ATC environment. In order to provide the back- 
ground information necessary for the analysis of the data 
link related results, this section gives an overview of the 
experiment design and the experimental conditions. 

Experiment setup- As in a previous experiment (refs. 1 
and 2), CTAS was used to create the 4D ATC environ- 
ment, and the TSRV simulator was used to simulate the 
4D-equipped aircraft. Both systems were linked through 
NASA’s Program Support Communications Network 
(PSCN). Other air traffic was simulated with the Ames 
Pseudo- Aircraft System (PAS), a system for real-time 
generation of multiple aircraft trajectories (unreleased 
material, “Pseudo-Aircraft System Documentation Pack- 
age,” R. Weske et al., Ames Research Center, 1990). The 
PAS aircraft trajectories are controlled by what is known 
as pseudo-pilots, whose main task is to simulate the 
pilots’ roles in air-ground communication. One pseudo- 
pilot handles several aircraft, using simple commands to 
control the aircraft in accordance with ATC instructions. 
For this experiment, PAS was provided with the capability 
for reception and acknowledgment of data-link messages. 

Since the timeframe for implementation of systems 
like the one under investigation is of the order of 
10-15 years, it was assumed that all the aircraft had 
RNAV (area navigation) capabilities. However, only the 
TSRV had the capability for accurate 4D navigation. The 
north-east Denver airspace (KEANN gate) was simulated 
with one high-altitude and one low-altitude sector. The 
traffic was controlled from en route cruise to the metering 
. fix, where the aircraft were handed off to the TRACON. 
The overall experiment setup is shown in figure 10. 


Controller subjects- Six active controllers from the 
Denver and the Dallas-Fort Worth Centers participated in 
the experiment. Four of the controllers had no previous 
experience with CTAS or a data link. For three consecu- 
tive weeks, teams of two controllers worked with the 
system (three teams). Depending on their experience with 
CTAS, they received 1.5 to 2.5 days of training on the 
DA, the data link, and the interaction with the 4D-FMS- 
equipped aircraft. The last 2 days of the week were used 
for the actual experiment, during which five test-runs 
were conducted. Each run involved approximately 1.5 hr 
of active control of traffic and included two flights of the 
TSRV. 

Traffic scenarios- The main arrival traffic flow was 
provided by the PAS. The TSRV-piloted cab was injected 
into that flow at precise times to create the described 
situations for the 4D-FMS-equipped aircraft. The TMA 
(sec. 2.2) was used to set up realistic traffic situations that 
met specific criteria with respect to the amount of delay to 
be absorbed and the geometry of the predicted conflicts. 
Three cases were considered for small delays (up to 
3 min), small enough to be absorbed on-route: (1) aircraft 
from different routes, merging during the descent phase, 
(2) aircraft on the same route (entrail), and (3) aircraft 
from different routes, merging while still in cruise. A 
fourth case was considered for moderate delays (up to 
8 min), which required that the aircraft be vectored off- 
route to absorb the delay by means of path-stretching. 

Controller procedures- The data link supported current 
ATC communication, as well as the advanced communi- 
cations required to deal with the 4D aircraft. It was 
assumed that all aircraft were data-link equipped. Since 
the main interest was in the profile negotiation process, 
the controllers did not have to use the data link for 
conventional ATC operations, but they were encouraged 
to do so. 

The following general strategy for controlling the arrival 
traffic through the high-altitude and low-altitude sectors 
was adopted. The high-altitude sector controller would try 
to set up a conflict-free traffic flow and absorb most of the 
delay, whereas the low-altitude sector controller would 
merge the traffic and control their descents. Delay would 
be absorbed by speed control and, if necessary, also by 
vectoring aircraft off-route (path-stretching). The handoff 
from the high to the low sector was prior to SMITY 
(fig. 2). For aircraft at lower cruise altitudes (FL310 and 
lower), the low-altitude sector issued the arrival clear- 
ances. For aircraft at higher cruise altitudes the high- 
altitude sector could issue the arrival clearance or descend 
the aircraft to altitudes that allowed the low-altitude sector 
to issue the clearance. 
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Data collection- During the 3 weeks of the experiment a 
total of 16 controller hours with data link were recorded, 
during which 19 successful TSRV flights were made. All 
data-link-related controller inputs and all data-link trans- 
missions were recorded. For the pseudo-aircraft, the 
pseudo-pilot commands were also recorded, both during 
the data-link runs and during 8 hr of simulation with voice 
only. At the end of each week, both team members filled 
out a questionnaire which contained several questions 
related to the data link. 

In the following sections the results obtained from the 
recorded data will be presented first, followed by the 
results of the questionnaire. Finally, some observations 
that were made by the experimenters are discussed. The 
analysis of the results focuses on the more “conventional” 
use of the data link. Advanced features, such as multiple- 
message sequences, processing of downlinked messages 
and automatic message transmission, will be discussed in 
separate documents. 

5.2 Analysis of Recorded Data 

Information was extracted from the recorded data for the 
following data-link parameters: 

1. Message rates, that is, the number of data-link 
messages uplinked per controller per unit of time 
(minutes) 

2. Message creation times, that is, the time elapsed 
between selection, by the controller, of an aircraft for 
data-link transmission and the actual transmission of the 
message 

3. Transaction times, that is, the time elapsed between 
transmission of a message and the reception of its reply 
(roger or unable) 

An overall summary of these data is shown in table 2. For 
each message type in the table the total message count, 
average message rate, mean creation time, and mean 
transaction time is given. The table shows that some of 
the message types were used infrequently and, therefore, 
provide insufficient data for further analysis. These latter 
types were (1) the tactical messages TRT, TLT, TR, TL, 
SPI, and SPD; (2) the navigation message RI; and (3) the 
free-text message FT. 

Three remarks need to be made, regarding these types: 

1. The tactical messages TRT, TLT, TR, TL, SPI, and 
SPD are all message types that would never be selected by 
the automatic application selection algorithms. This 
means that the DCP would never show any of these 
messages as the initial selection. The infrequent use can 
mean two things: the HE and SP messages provide suffi- 


cient flexibility to be used most of the time, or it is too 
cumbersome to select and modify the other types of 
heading and speed messages. This has not been investi- 
gated and there have been no controller comments with 
regard to this issue. 

2. The controllers never used the route-intercept message 
(RI) through the data link, although they did use it a few 
times with voice communication. The controllers took 
advantage of the RNAV capabilities of the aircraft, in 
combination with the waypoint capture mode of CTAS, to 
let aircraft capture their original routes and resume their 
own navigation. 

3. The free-text message (FT) was never used. Controllers 
used voice for messages that were not available as stan- 
dard data-link messages, and, in some cases, for example, 
for explanatory messages (sec. 4.3), they did not send the 
message at all. 

For the remaining message types (DA, 4D, REQ, HE, AL, 
SP, PD, and VF), the data-link parameters are discussed in 
more detail. Some of these parameters are not only a 
function of the application (message type), but also of the 
controller or flight crew and the type of sector (high or 
low altitude). Controller crew dependency may be related 
to differences in controller preference for voice or data 
link, different strategies for controlling traffic, and differ- 
ences in proficiency. The sector dependency may be due 
to the fact that there is a division of tasks between sectors; 
in this case the high sector would set up a conflict-free 
traffic flow and do most of the delay absorption (vector- 
ing), whereas the low sector would merge the traffic and 
issue most of the arrival clearances. The transaction times 
are dependent on the flight crew and not on the controller 
crew, since those times reflect how long the flight crew 
takes to respond to uplinked messages. Both for controller 
and pilot crews, the data are presented as the average of 
both crew members. 

In the next sections, the different data-link parameters will 
be analyzed. First, analysis of the message rates is used to 
confirm that the general strategy for controlling the traffic 
through the high-altitude and the low-altitude sector was 
indeed as intended. Second, the creation times are ana- 
lyzed to show the significant benefit of data-link integra- 
tion in CTAS for the controller. Finally, the transaction 
times the controllers had to deal with, are discussed. Fig- 
ures 11 through 13 are used to illustrate the results. 

Except for figure 12(a), the vertical axis in these figures 
shows the parameter of interest; the horizontal axis shows 
the various message types (applications) under considera- 
tion, in the following order: strategic (DA, 4D and REQ), 
tactical (HE, AL, and SP), navigational (PD) and 
frequency change (VF). 
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Message rates- The message rate is the average number 
of messages uplinked per controller per unit of time 
(minutes). To compensate for different simulation times, 
the totals of the message counts (for each message type, 
controller crew, and sector) were divided by the elapsed 
time. The results are presented in figure 11. Figure 1 1(a) 
shows the message rate for each message type. In fig- 
ure 11(b) these rates are given as a function of the con- 
troller crew (weeks 1-3), and the sector (high or low). 

The results for the strategic, tactical, and navigation 
messages confirm that the way the arrival flow through 
the high and low sector was handled was indeed as 
intended (see sec. 5.1): the high-altitude sector tried to set 
up a conflict-free traffic flow and absorb most of the 
delay, whereas the low-altitude sector merged the traffic 
and controlled their descents (by means of the arrival 
clearances). For each message category a brief 
explanation is given below. 

Strategic messages: The rates for the 4D and REQ 
message are much lower than the rate for the DA 
message: the 4D and REQ messages were used only for 
the TSRV, whereas the DA message was used for all 
other aircraft. The DA and 4D rates in figure 1 1(b) show 
that most arrival clearances are issued in the low-altitude 
sector. However, more requests are sent in the high- 
altitude sector. Reference 3 gives a detailed description of 
the use of the 4D and REQ message, as part of the profile 
negotiation process. Note in figure 1 1(b) that the first 
controller crew never issued a 4D clearance in the high 
altitude sector. 

Tactical messages: Of the tactical clearances, speed 
instructions are issued most often (fig. 1 1(a)): twice as 
often as altitude instructions and three times as much as 
heading instructions. This is related to the fact that CTAS 
always tries speed adjustment first to meet an arrival time. 
Altitude and heading are used by the controller to make 
up delays above that absorbed by speed change, or to 
resolve conflicts. The high-altitude sector issued most of 
the tactical clearances (fig. 1 1(b)). 

Navigation messages: The high-altitude sector 
issued most of the PD commands, to bring aircraft back 
on route after a path-stretch maneuver. The actual 
merging of aircraft into one main arrival flow took place 
in the low altitude sector. 

Frequency-change message: The number of 
frequency-change messages is roughly the same for both 
sectors. This is not surprising, since all of the arrival 
traffic under consideration went through both sectors. 

Figure 1 1 also shows that the second controller crew 
issued fewer heading and altitude instructions by data 
link. They had a slight preference to use voice for these 


messages, probably related to the way these messages are 
created, which is discussed in the next section. 

Creation times- Creation time is defined as the time 
elapsed between selection, by the controller, of an aircraft 
for data link and the subsequent transmission of a 
message to that aircraft. It covers the time the controller 
needs to select the application, modify the message (if 
necessary), and approve its transmission. Creation times 
are an indication of the time the controller spends com- 
municating by data link. However, they should be inter- 
preted with care: between selection of an aircraft for data 
link and approving the message for transmission, a con- 
troller may perform some tasks that are not related to the 
creation of the message. 

Figure 12(a) shows the distribution of the message 
creation times. The frequency distribution shows a clear 
peak at 2 sec creation time. The cumulative frequency 
distribution shows that 61% of the messages were created 
and sent in less than 5 sec; 95% in less than 17 sec. The 
data show no clear upper limit for the creation time. A 
relatively high percentage (3%) of messages has a cre- 
ation time of more than 20 sec. For longer creation times 
it is likely that as already mentioned above, the controller 
performed other tasks in parallel with the message 
creation process. 

Table 3 and figure 12(b) present creation times for each 
message type separately. The creation times are presented 
as the sum of the mean time required for selection, modi- 
fication, and approval of a message. These three compo- 
nents are discussed separately below. They show that the 
integration of the data link into CTAS, as described in 
section 4.4, has provided a considerable benefit for the 
use of the data link by the controller. 

Application selection: The selection times give an 
indication of the quality of the automatic application 
selection algorithms and the design of the DCP (sec. 4.2). 
There are some interesting issues; for example, does the 
DCP come up with the desired application when an air- 
craft is selected for data link, and how many inputs are 
required and how long does it take to select a particular 
application on the DCP. It was found that for 64% of the 
messages approved by the controller, the DCP came up 
with the proper application. This includes the shortcuts 
that were available to select the AL and SP message (see 
sec. 4.4). 

For the selection times, the following information can be 
retrieved from table 3 and figure 12(b). The selection time 
was zero for the VF message: the DCP always came up 
correctly when this message was required. The mean 
selection time was only 0.2 sec for the DA message, 

which means that the software anticipated most of the DA 

/ 
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messages correctly. The mean selection time was the 
longest (4.9 sec) for the PD message: this message always 
required one manual input for selection, since it was not 
included in the automatic selection algorithms. 

Message modification: When not satisfied with the 
message text presented on the DCP, the controller can 
modify the contents of that message. An example is 
changing the target value of a heading instruction. Fortu- 
nately, as a result of the integration of the data link into 
CTAS, many messages can be approved without modifi- 
cation. This is illustrated in figure 12(b) and table 3(b), 
which show that only tactical messages (HE, AL, and SP) 
required modification. For the nontactical messages, the 
message text is automatically created from the informa- 
tion available in the aircraft data base. In this experiment, 
the nontactical messages comprised 55% of the total 
number of messages sent by the controllers. However, 
also for the tactical messages, it is possible that the DA 
provides the desired target value, for example, when there 
is a DA cruise speed advisory (see sec. 4.4). In this exper- 
iment, only 54% of the HE, AL, and SP messages 
required additional inputs. In total, for 75% of the mes- 
sages the controller directly used the initially proposed 
message text. 

Table 4 presents a more detailed overview of message 
creation times for the HE, SP, and AL messages. The 
table shows the significant difference between messages 
that did and did not require modification. For the tactical 
messages that did require modification, an average of 
5.2 modifications per message (i.e., the number of entries 
in the DNP or keyboard to enter the proper value) was 
recorded, at a mean creation time of 10.4 sec per message. 
Only 3.5 sec, and zero inputs, was recorded for the 
tactical messages that did not require modification. 

Message approval: The mean time required to 
approve a message was 3.1 sec. This approval time is the 
time between the last selection or modification of a 
message by the controller and clicking on the “send” 
button on the DCP. Higher values for the 4D, REQ, and 
PD messages can be accounted for by what was men- 
tioned at the beginning of this section: after selecting the 
aircraft, controllers performed different tasks (such as 
reviewing the traffic situation) before they actually 
approved the message for transmission. 

Figure 12(c) presents creation times as a function of crew 
and sector. The results indicate that there is no clear rela- 
tion between creation times and these parameters. For 
example, the tactical-message creation times for the first 
crew are longer in the high- than in the low-altitude 
sector; the second and third crew show the opposite. Of 
the nontactical messages, the VP message shows longer 


times for the low-altitude sector, whereas the PD message 
shows the opposite. 

Transaction times- Transaction times are measured as 
the time difference between sending a message from a 
sector and receiving the reply at the same sector. They 
cover the time required for uplink of the message, the 
time the pilots need to review and respond to the message, 
and the transmission time of the reply. Since no data-link 
delays were modeled in this experiment, the transmission 
times were relatively small. 

Transaction times describe the speed with which uplinked 
messages are acknowledged. The controller has no influ- 
ence on these times, but must deal with them. They are 
analyzed in detail for the 4D-FMS-equipped aircraft only, 
since that was the only aircraft in the experiment that was 
simulated by a cockpit simulator (the TSRV) and flown 
by operational pilots as a real aircraft. Unfortunately, the 
flight crews only received half a day of training, so that 
they were not fully proficient with the data link. 

The mean transaction time for tactical messages was 
9.4 sec for the TSRV. In reference 7, which combines 
several data-link studies, 10 sec is given as a mean value 
(not including transmission times). By comparison, the 
mean transaction time for the aircraft simulated by the 
PAS and controlled by the pseudo-pilots, was only 
3.9 sec. 

Figure 13(a) shows the mean transaction time per message 
type for the TSRV. In figure 13(b) the results are given 
per flight crew and control sector. Note that data are pre- 
sented for the first and second flight crew only. Data for 
the last crew were discarded, because that crew chose to 
conduct real-time discussions with the observing engineer 
before responding to most of the data-link messages. The 
DA message is not included in the analysis: for the TSRV, 
only the 4D message was used to issue arrival clearances. 
“Missing” bars in figure 13(b) (for example, for the 
speed-message for the second flight crew in the low- 
altitude sector) indicate that for the 4D-FMS-equipped 
aircraft the corresponding message type was never used 
by the controller crew in that sector. 

Overall, the transaction times are not very sensitive to the 
message type. The data indicate a slightly larger response 
time for the strategic messages (4D and REQ) than for the 
tactical (HE, AL, and SP) and navigational (PD) mes- 
sages. Strategic messages are more complex and lengthier 
than the other messages and are likely to take more time 
to be reviewed by the pilots. 
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5 3 Analysis of Questionnaires 

All six controllers filled out a questionnaire with several 
questions related to the data link. There were two types of 
questions: subjective ratings and short answers. The data- 
link-related results, which give an indication of controller 
acceptance, panel ratings, data-link advantages, and 
several other aspects of the data link, are summarized 
below. 

On a scale of 1 to 6, the controllers rated their preference 
of data link compared to voice (1 = data link preferred; 

6 = voice preferred) for different applications. In figure 14 
the results are summarized for tactical (HE, AL, and SP), 
navigational (RI and PD) and strategic (DA, 4D, REQ) 
message categories. The horizontal axis represents the 
rating scale, with preference for data link on the left and 
voice preference on the right. The vertical axis shows the 
number of controller responses for each rating. With all 
ratings on the left, the results show that data link is 
strongly preferred for all categories, with a slightly higher 
rating for the strategic messages. Strategic messages are 
complex and lengthy, but nevertheless very easy to send 
by data link. 

The controllers were also asked to rate, on a scale of 
1 to 6, each of the data-link panels, DCP, DNP, DSP, and 
DHP (see sec. 4.2). The ratings, which considered useful- 
ness, clarity, ease of use, and need for further improve- 
ment, are presented in figures 15(a)-15(d). Again, the 
rating is on the horizontal axis, with the most favorable 
rating on the left; the number of controller responses for 
each rating is on the vertical axis. From figure 15(a) it is 
clear that the controllers find the data-link panels easy, if 
not very easy, to use. The ratings for usefulness and 
clarity show similar results (figs. 15(b) and (c)). Never- 
theless, the controllers also indicate that there is some 
need for further improvement (fig. 15(d)), although the 
only concrete suggestion was to highlight certain informa- 
tion in the message text on the DCP. One controller never 
used the DHP, and therefore did not rate it. 

The controllers agree, or strongly agree (rating 1 or 2 on a 
scale of 1 to 6), with the following statements: 

1. It is easy to create a data-link message for uplink 

2. The DSP is a “good” way to keep track of the 
communication situation 

3. Using data link for air/ground communication does 
not increase workload (one controller agreed slightly) 

4. Using data link for air/ground communication does 
not distract from other tasks 


5. Data link should be the primary means for transfer of 
control to the next sector (sending the frequency-change 
message) 

The controllers’ opinions were more varied (varying or 
even opposite ratings on a scale of 1 to 6) on the 
following issues: 

1. The data-link interface should not be separated from 
the DA interface: on average the controllers agree (ratings 
vary from “slightly disagree” to “fully agree”). They find 
the CTAS/data-link synergism in terms of CTAS using 
data-link information and vice versa more important than 
an integrated data-link interface. 

2. It is acceptable that specific messages are automati- 
cally removed from the DSP (in particular rogered 
messages): some controllers agree, some disagree. This 
can easily be adapted to a controller selectable feature. 

3. The DCP should “stay” up after a message is sent: the 
replies indicate that this should be a controller’s choice, 
which is currently the case. 

The controllers confirmed that in many cases, the DCP 
comes up with a message type different from what they 
intend to send. Furthermore, they indicated that, in gen- 
eral, the initially proposed value for the tactical messages 
is not good. Actually, the recordings show that in 66% of 
the cases the correct message was automatically selected, 
and 46% of the tactical messages did not require modifi- 
cation (sec. 5.2). The controllers* opinions indicate, that 
they would like the automation to anticipate their actions 
even better. A thorough analysis of the cases in which the 
selection rules (sec. 4.4) failed is needed to determine 
how those rules can be improved. 

In the responses to a short-answer questions on the main 
advantages of the data link, the controllers mentioned the 
following: reduced frequency congestion, fewer commu- 
nication errors, and reduced overall workload. In reply to 
another question, on specific situations that required 
additional voice communication, the controllers indicated: 

1 . When an aircraft had to report leaving an altitude 

2. When no response to a clearance was received within 
a “reasonable” time interval and the controller wanted to 
find out if the clearance had been received (see next 
section) 

3. When a pilot could not comply with a clearance 
(“unable” reply) and had to send an explanation 

The controllers indicated that most data-link-related errors 
occurred when using the mouse and the DNP for input or 
adjustment of a new message value. This is confirmed by 
experimenter observations, discussed in the next section. 
There was only one suggestion for improving the use of 
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the data link and that was to provide some audio-feedback 
to support the visual information (e.g., sound a beep when 
a message is received). The general opinion was that the 
data link should be operationally available as soon as 
possible. 

5.4 Experimenter Observations 

During the experiment, a number of observations were 
made by the experimenters. Some of these could only be 
partially confirmed by the questionnaire or the data. The 
most significant observations are discussed below. 

1 . The way controllers handled data-link communica- 
tions differed from the way they handled voice communi- 
cations. With voice, the controllers usually waited for a 
pilot to reply to a message and used the reply to verify 
that the message was received properly, before they 
addressed another aircraft. With data link, this sequential 
process was replaced by a parallel process in which the 
controllers did not wait for a reply before they sent a 
message to the next aircraft. This difference is consistent 
with the results of other experiments, as described in 
reference 7. For this experiment, the data show that in 
32% of the overall time there were one or more messages 
on the DSP for which a reply had not yet been received. 

In 28% of that time (i.e., 9% of the overall time) there 
were two or more messages that had not been replied to, 
with a maximum of five messages simultaneously. 

Another difference between voice and data link was that 
the controllers spent very little time in dealing with the 
data-link replies. This is related to the fact that most 
replies are a mere “roger” and do not give any readback of 
the uplinked message. Only when there was an unable 
reply, or no reply at all, did the controllers have to take 
further action. 

2. The controllers did not appear to be sensitive to 
transaction times, as long as those times did not exceed a 
certain limit. The lack of sensitivity is illustrated by the 
fact that there was no difference in dealing with the TSRV 
or with the other aircraft, even though average transaction 
times were 9.4 sec for the TSRV and 3.9 sec for the 
pseudo-aircraft (tactical messages only). However, if a 
reply was not received within approximately 40 sec, the 
controllers would start wondering (they verbally 
expressed their doubt about whether the message was 
actually received on board) and after roughly 1 min they 
would inquire by voice whether the message had been 
received. This occurred several times when the data-link 
connection between CTAS and the TSRV failed, and with 
the third pilot crew, which used exceptionally long times 
to respond to uplinked messages. The controllers indi- 
cated that it might be useful to have feedback on message 


delivery, that is, as soon as a message is received at the 
destination, a signal should be sent back to indicate to the 
controller that the message was delivered. This “technical 
acknowledgment” is comparable to a “standby,” used for 
voice communication. Also, if a message cannot be deliv- 
ered, then the source should receive an indication of that 
problem, provided that the source can still be retrieved 
from the message. 

3. Comparing the data-link runs with the voice-only 
runs, it became clear that data link provided a precise and 
concise exchange of information. The clarity of commu- 
nication is illustrated by the fact that it was never required 
to send a data-link message twice because a pilot could 
not understand the message. This was not the case when 
voice communication was used. In particular, for the 
complex strategic messages it was much easier to use data 
link than to use voice. The strategic messages are lengthy 
and take much more time to communicate by voice (for 
issuance and readback). With data link, these messages 
are automatically composed and take comparatively little 
time to select and approve for transmission and, provided 
future data link has reliable message delivery, the lengthy 
verbal readback is avoided. 

4. The experiment clearly showed a large reduction of 
frequency congestion. The percentage of messages sent by 
data link varied per controller team. The data indicate that 
between 50% to as much as 90% of the messages were 
sent by data link. The sound level in the control room was 
substantially lower for the data-link runs than for the 
voice-only runs. 

5. The controllers always positioned the data-link panels 
on their traffic display such that these panels would not 
overlap their main area of interest. It was clear that they 
did not want to hide any of their radar information. This 
was the case even when they used the “pop” option on the 
DCP (sec. 4.2), which lets the DCP and DNP only on the 
controller display when they are actually creating a mes- 
sage. Figure 9 gives an example of how the datalink 
panels were typically positioned. 

6. Most data-link-related errors occurred when using the 
mouse and the DNP for input or adjustment of a new 
message value. The consequence of such an error was 
either that the controller had to make additional inputs to 
correct the errors or, in a few cases, that the wrong value 
was uplinked. Fortunately, these errors are of a sort that 
can be recognized easily by a message- validation algo- 
rithm. For this experiment, such an algorithm was not 
available. . 

7. Some controllers used the DHP as electronic flight 
strips, since the DHP has information on all the clearances 
issued via data link. They invoked the panel to check 
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whether a specific message was sent or a reply received. 
Furthermore, on the DHP they could check the exact mes- 
sage text (in CTAS format) transmitted for the lengthy 
messages dealing with the 4D aircraft. For these mes- 
sages, the DCP or DSP only showed a shortened version 
of the message text. 

The overall results of the experiment, combining observa- 
tions, recordings and questionnaires, are summarized in 
the next section. 

6. Conclusions 

An air-ground data-link system was developed to investi- 
gate integration of aircraft and ATC system capabilities. 

In the previous sections, the design and experimental 
evaluation of the ground-based portion of this data-link 
system were described. The results of the experiment 
allow several conclusions to be drawn with respect to the 
data link. These are summarized below, together with 
recommendations for further study and development. 

The controllers responded favorably to the data-link capa- 
bility. Furthermore, several technical advantages of data 
link were demonstrated, such as improved clarity of 
complex communications and reduced frequency conges- 
tion. Of greater significance was the synergism gained 
from integrating data link with CTAS. The information 
transmitted via data link was used to improve the 
monitoring and analysis capability of CTAS without 
increasing controller input workload. Conversely, CTAS 
was used to anticipate and create prototype messages, thus 
reducing the workload associated with the manual 
creation of data-link messages. 

Overall, it was found that the initial design requirements, 
as set out in section 1, were clearly met: 

1. The data-link system was able to support conven- 
tional ATC communications, as well as the complex 
communications developed to deal with the 4D-FMS 
capabilities of the TSRV. 

2. The use of this data link was accepted by the con- 
trollers. The data link was useful, clear, and easy to use 
and for most applications data link was preferred to voice. 

3. During the development process, the data-link system 
proved to be easily adapted and expanded. 

Based on the outcome of this experiment, it is recom- 
mended that the data-link interface be improved and that 
new experiments be conducted, addressing, for example, 
the following: 

1 . Optimization of the data-link protocol 


2. Determination of the optimal set of data-link 
applications 

3. Optimal design for the various data-link panels 

Furthermore, some operational aspects of the data link 
that have not been looked at for this experiment, should 
be investigated: 

1 . A mix of data-link equipped aircraft and aircraft not 
so equipped 

2. Transmission delays in the air-ground data-link 
communication chain 

3. Large-delays/heavy-traffic conditions 

4. Two controllers working a sector 

Despite these open issues, it is clear that integrating data 
link with an advanced automation system, such as CTAS, 
creates a large potential for development of an opera- 
tionally suitable tool for air-ground data communication. 
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Table 1. Applications available on the Data-Link Control Panel 


Button 

Category 

Code 

Message text on the DCP 

i 

Strategic 

DA 

<DA clearance> e.g., “DA RI 56 .70/280” 



4D 

“Cleared <arrival-procedure> at <time>” 



REQ 

“Request cross <MF> at <time>” 

2 

Heading 

TRT 

‘Tum_right_to ...” 



TLT 

“Tum_left_to ...” 



HE 

“Flyjieading ...” 



TR 

“Tum_right ... degrees” 



TL 

“Tumjeft ... degrees” 

3 

Altitude 

AL 

“Altitude ...” 

4 

Speed 

SP 

“Fly_speed ... knots,” or 



SP 

“Fly_speed ... ” (Mach no.) 



SPI 

“Increase_speed ... knots” 



SPD 

“Decrease_speed ... knots” 

5 

Navigational 

PD 

“Proceed_direct_to ...” 



RI 

“Intercept ...” 

6 

Frequency-change 

VF 

<facilityxtype> on <freq> e.g., “Denver center on 123.45” 

7 

Free text 

FT 

<free text> 


Table 2. Overview of measured data-link parameters: Total elapsed time 944 min 


Message type 

Code 

Message count, 
all aircraft 

Message rate, 
all aircraft, 
per min 

Creation time, 
all aircraft, 
sec 

Transaction time, 
TSRV only, 
sec 

DA arrival clearance 

DA 

198 

0.21 

3.7 

_ 

4D arrival clearance 

4D 

18 

0.02 

7.8 

12.2 

Request for profile 

REQ 

50 

0.05 

11.0 

14.0 

Tum-right-to 

TRT 

0 

0.00 

— 

— 

Tum-left-to 

TLT 

1 

0.00 

29.0 



Heading 

HE 

93 

0.10 

10.7 

10.0 

Tum-degrees-right 

TR 

5 

0.01 

8.8 

— 

Tum-degrees-left 

TL 

9 

0.01 

13.6 

— 

Altitude 

AL 

160 

0.17 

8.7 

8.8 

Speed 

SP 

320 

0.34 

5.6 

9.4 

Increase-speed 

SPI 

4 

0.00 

13.3 

— 

Decrease-speed 

SPD 

2 

0.00 

31.5 

— 

Proceed-direct-to 

PD 

73 

0.08 

9.0 

9.6 

Route-intercept 

RI 

0 

0.00 

— 

— 

Frequency change 

VF 

382 

0.40 

2.9 

12.0 

Free text 

FT 

0 

O.O0 

— 

— 


Total 

1315 

1.39 

Mean: 5.8 

Mean: 11.9 


Table 3. Message creation-time components and input counts 


Type 

Creation time components, sec 
Select Modify Approve Total 

Input counts 
Select Modify 

DA 

0.2 

0.0 

3.5 

3.7 

0.4 

0.0 

4D 

2.8 

0.0 

5.0 

7.8 

1.2 

0.0 

REQ 

2.5 

0.0 

8.5 

11.0 

1.5 

0.0 

HE 

2.7 

4.7 

3.3 

10.7 

0.9 

6.6 

AL 

2.1 

4.4 

2.2 

8.7 

0.7 

4.4 

SP 

1.5 

1.7 

2.4 

5.6 

0.5 

0.9 

PD 

4.9 

0.0 

4.1 

9.0 

1.0 

0.0 

VF 

0.0 

0.0 

2.8 

2.8 

0.0 

0.0 


Table 4. Differences in mean creation times for modified and unmodified tactical messages (Total number of 
messages considered: 1315) 


Tactical message 

Heading (HE) 

Altitude (AL) 

Speed (SP) 

Total 

Unmodified messages 

6 

14 

242 

262 

Mean creation time, sec 

6.8 

2.7 

3.5 

3.5 

Modified messages 

87 

146 

78 

311 

Average creation time, sec 

10.9 

9.2 

12.2 

10.4 

Mean no. of modifications 

7.0 

4.9 

3.8 

5.2 

All messages 

93 

160 

320 

573 

Mean creation time, sec 

10.7 

8.7 

5.6 

7.3 


Outside world CTAS 


Center Controllers Traffic Manager TRACON Controllers 



Figure 1. Center/TRACON Automation System (CTAS) concept 





Figure 2. DA planview display with timeline, DA advisory panel and several data-link panels. 
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HE230 1120534 
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NASA515 
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343 


Shown message text 
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Hdg 230 
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120534 


(b) 


Figure 3. Comparison of CTAS and transmission message format structure. 



Figure 4. Clearance and informatbn dialogues. 
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Figure 5. Request-for-information dialogue. 
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Figure 6. Data-link control panel (DCP). 
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Figure 7. Data-link numeric panel (DNP). 
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Figure 8. Data-link status panel (DSP). 
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Figure 9. Data-link history panel (DHP). 
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Figure 10. Experiment setup for the 4D Aircraft/ ATC Integration Study. 
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Figure 1 1. Data-link message rates (all aircraft), (a) Average message rate as a function of message type; (b) average 
message rate as a function of message type, controller crew, and sector. 
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Figure 12. Data-link message creation times (all aircraft), (a) Message-creation time distribution; (b) mean message - 
creation time and time components as a function of message type; (c) mean message-creation time as a function of 
message type, controller crew, and sector. 
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Figure 13. Data-link transaction times (TSRV only), (a) Mean data-link transaction time as a function of message type; 
(b) mean data-link transaction time as a function of message type, controller team, and sector. 
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Figure 14. Controller preference of data link to voice for different categories of applications (six controller subjects). 
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Figure 15. Controller ratings of several aspects of data-link panels (six controller subjects), (a) Rating for ease of use of 
data-link panels; (b) rating for usefulness of data-link panels; (c) rating for clarity of data-link panels; (d) rating for need for 
further improvement of data-link panels. 
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Appendix. Description of Data-Link Message Types and Formats 

This appendix provides a description of the available data-link message types and the different formats used for coding 
the message contents in the message text (see sec. 3.2 of main text). For each message type used in the experiment, three 
different formats are described: 

1. CTAS format, used for handling messages in the DA and for internal communication between DAs and the cm 

2. Format used for transmission of messages to/from the TSRV at Langley 

3. Format used for data-link communications with aircraft simulated by the Pseudo- Aircraft System (PAS) at Ames 

For each message type the following information is given: 

Code: Description 

RT phraseology : equivalent RT (voice) message 

CTAS: CTAS format CTAS example 

TRX: format for transmission transmission example 

PAS : PAS format PAS example 


The “code” specifies the message type. Under CTAS, each message type is represented by an integer number. This 
message number is not included in the format description. For transmission, the message type is represented by a three- 
character code, included in the description. For PAS, there is no separate message type: the message text gives sufficient 
information for message processing. 

The basic format for transmission to/from the TSRV is an ASCII string of up to 220 characters: 
DDDSSSTTT:ccccc:HHMMSS:<CR> 


with 


DDD 

destination; 

SSS 

source; 

TTT 

message type (TSRV specific); 

ccccc 

message text (variable length); 

HHMMSS 

sequence number (hr, min, sec); 

<CR> 

carriage return (decimal 13). 


The transmission format description covers the portion TTTxcccc. 

The CTAS format has been generalized, which means that certain parts of the format can be changed without affecting 
the message processing. In the format description this is indicated by “word,” which can be replaced by any suitable 
word. Uppercase items represent fixed-length fields; lowercase items are for variable-length fields. Items between paren- 
theses are optional. Those parts of the general formats that are fixed are printed in bold. 

The meaning of the various format descriptors is as follows: 


word 

# 

C, c 

D, d 

X, x 

Y, y 
K,k 
M, m 
R,r 

NNNNNN, nnnnnn 


any suitable word 

one or more blanks (spaces) 

character 

digit 

x-coordinate (n. mi. for CTAS; deg for transmission) 

y-coordinate (n. mi. for CTAS; deg for transmission) 

speed, knots 

Mach number 

range or distance, n. mi. 

message sequence number 



preceding page blank not filmed 
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HHMMSS, hhmmss time in hours, minutes, seconds 
N.A. Not available 


First, the message types that have a corresponding application button on the data-link control panel are described. They 
are followed by some additional message types for uplink and the message types for downlink. 

Strategic Messages 

DA: Arrival clearance with DA advised descent profile 

RT phraseology : “Cleared for the <arrival-procedure-name> arrival, begin descent at <tod-dist> DME, descend at 
(Mach .MM, ) KKK knots indicated” 

CTAS : word#CC#rrr#(m.mm#)kkk#ccc DA RI 58 .70 280 GOLDN 

TRX: TAC:DARRRMMKKK:CLRccc TAC:DA05870280:CLRGOLDN 

PAS : DME#ccc#m#(Mmm#)Skkk DME GOLDN 58 M70 S280 

remarks: CC can be RI - Route Intercept, WC - Waypoint Capture, PS - Path Stretch; ccc = arrival procedure name 

4D : 4D arrival clearance 

RT phraseology : “Cleared for the <arrival-procedure-name> arrival, (begin descent at <tod-dist> DME, descend at 
(Mach .MM, ) KKK knots indicated,) cross <meter fix name> at <time>” 

CTAS : word#ccc#word#HHMMSS Cleared KEANN at 190524 

TRX: TAC:CLRccc:MTHHMMSSccc TAC:CLRKEANN:MT190524SWEET 

PAS : N.A. 

Remark: if descent constraints are specified, this message is sent in conjunction with the profile (PRO) message, 
described under the additional messages. 


REO: 

Request for profile 


RT phraseology: 

“(Expect direct to <waypoint name>,) ( expect meter fix time of <arrival time>.) what is your profile 
request?” 

CTAS: 

(CC#ccccccc)(#hhmmss) 

PS PONNY.J 1 14.KEANN 170605 


(CC can be PS - Path-stretch, PD - Proceed-direct, RI 

- Route-intercept, OR - On Route) 

TRX: 

REQ:RTcccccccc(:PS/:PDccccc)(:MTHHMMSS) 
REQ:RTPONNY.J 1 14.KEANN:PSPONNY: 1 70605 


PAS: 

N.A. 


Heading Messages 


HE: 

Heading instruction 


RT phraseology: 

“Maintain heading DDD” 


CTAS: 

word#ddd 

Fly_heading 50 

TRX: 

TAC:HEDDD 

TAC:HE050 

PAS: 

Fddd 

F50 

TLT: 

Turn-left- to instruction 


RT phraseology: 

‘Turn left to DDD” 


CTAS: 

word#ddd 

Tum_left_to 240 

TRX: 

T AC : HETLTDDD 

TAC:HETLT240 

PAS: 

Lddd 

L240 

IEL: 

Tum-right-to instruction 


RT phraseology : 

‘Turn right to DDD” 
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CTAS: 

TRX: 

PAS: 


word#ddd 

TAC:HETRTDDD 

Rddd 


Turn_right_to 340 

TAC:HETRT340 

R340 


3L: 

RT phraseology : 
CTAS: 

TRX: 

PAS: 


Tum-degrees-left instruction 
‘Turn left ddd degrees” 
word l#ddd#(word2) 
TAC:HETLDDD 
Gddd 


Tum_left 30 degrees 

TAC:HETL030 

G30 


TR : Tum-degrees-right instruction 

RT phraseology: ‘Turn right ddd degrees” 
CTAS: wordl#ddd#(word2) 

TRX: TACtHETRDDD 

PAS: Dddd 


Tum_right 15 degrees 

TAC:HETR015 

D15 


Altitude Messages 

Altitude is given in hundreds of feet, both above and below transition-level/altitude. The translation to transmission 
format depends on the position of the target altitude relative to the current altitude. 


AL: 

RT phraseology: 
CTAS: 

PAS: 

RT phraseology: 
TRX: 

RT phraseology: 
TRX: 

RT phraseology: 
TRX: 


Altitude instruction 
various (see below) 
word#ddd 
Addd 

“Climb and maintain <altitude or FL>” 
TAC:ALCDDD 

“Descend and maintain <altitude or FL>” 
TACrALDDDD 
“Maintain <altitude or FL>” 
TAC:ALMDDD 


Altitude 290 
A290 

TAC:ALC290 

TAC:ALD080 

TAC:ALM350 


Speed Messages 

SE: 

RT phraseology: 
CTAS: 

TRX: 

PAS: 


Speed instruction 

“Maintain kkk knots” or “Maintain Mach .MM” 
word#kkk or word#m.mm 
TACrSPKKK or TAC:SP.MM 
SkJck or Mmm 


Speed 250 or Speed .67 
TAC:SP250 or TAC:SP.67 
S250 or M67 


Remarks: This message is used for CAS and Mach commands; for Mach: 0 < speed < 1.0 


SPI : 

RT phraseology: 
CTAS: 

TRX: 

PAS: 


Increase-speed instruction 
“Increase speed kk kts” 
wordl#kk#(word2) 

N.A. (We used TAC:FTIncrease speed kk kts) 
Ckk 


Increase_speed 20 kts 
C20 


SPD : 

RT phraseology: 
CTAS: 

TRX: 

PAS: 


Decrease-speed instruction 
“Decrease speed kk kts” 
word 1 #kk#( word2) 

N.A. (We used TAC:FTDecrease speed kk kts) 
C-kk 


Decrease_speed 20 kts 


C-20 



Navigation Messages 


£ 1 : 

RT phraseology : 
CTAS : 

TRX: 

PAS: 


Route-intercept instruction 
“Intercept <route name>” 
word#cccc 
TACtRIcccc 
INT#cccc 


Intercept J 114 
TACrRUl 14 
INTJ114 


ED: 

RT phraseology: 
CTAS: 

TRX: 

PAS: 


Proceed-direct-to instruction 

“Proceed direct to ccapture waypoint name>, resume own navigation” 
word#ccccc Proceed_direct_to SMITY 

TAC:PDccccc:HERE TAC:PDSMITY:HERES 

CAP#ccccc CAP SMITY 


Frequency Change Message 


YE: Frequency-change instruction 

RT phraseology: “Contact <facility name> <facility type> on <frequency>” 
CTAS: wordl#ccc#ccc#word2#lDD.dd 

TRX: TACrVFDDDDDcccCCC 

PAS: HO#ccc (PAS sector identifier) 


Contact Denver Center on 123.750 

TAC:VF23750DENCNT 

HO S9 (HO TRA for TRACON) 


Free-Text Messages 


FT: 

RT phraseology: 
CTAS: 

TRX: 

PAS: 


Free text message 

any non-standard free-text message 

cccc (up to 51 characters) 

TAC:FTcccc 

FT:#cccc 


Report current heading 
TAC:FTReport current heading 
FT: Report current heading 


Additional Messages 
Genera] remarks: 

1 . Under the current data-link procedures, a 4D clearance is issued as a sequence of three messages, sent when the 
controller approves the “4D” application on the DCP. The sequence consists of a route clearance (ROU), an arrival clear- 
ance (4D), and additional profile constraints (PRO). The route is sent only if the new route differs from the last cleared 
route. 

2. The information (INF) message is used only for low-priority, automatically generated information. For example, 
when the controller enters a downlinked profile message (PRO) into the DA’s trajectory analysis, a “Profile receive, 
standby” is uplinked automatically. 


ROU : Route clearance 

RT phraseology: “cleared for the route <route> 

(, proceed direct to (, at your discretion))” 

CTAS: CC#cccccccc PD PONNYJ1 14.KEANN 

TRX: ROU:RTcccccccccccc(:PSccccc or :PDccccc) 

ROU :RTPONNY.J 1 14.KEANN:PDPONNY 
PAS: N.A. 

Remarks: The ROU message is always sent in conjunction with the 4D arrival clearance message (see before). 
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PRO : Profile constraints 

RT phraseology : (see 4D message) 

CTAS: ccccc#hhmmss#xxx#yyy#m.mm#m.mm#kkk#mT#rrr 

GOLDN 170515 234.34 456.20 .72 .72 295 0764 58 
TRX: PRO *ccccc *HHMMS S * NXXXXXXX WXXXXXXX: *MM :.MM: KKK.RRRR 

PRO : GOLDN: 1705 15:N0404507W1024915:.72:.72:295:0764 

PAS: N.A. 

Remarks: The PRO message is always sent in conjunction with the 4D arrival clearance message (see before). 


INF : 

RT phraseology: 
CTAS: 

TRX: 

PAS: 


Information message 

any non-standard informative message 

ccccc (up to 202 characters) 

INF:ccccc (up to 202 char.) 
Info:#ccccc 


Profile received, standby 
INF:Profile received, standby 
Info: Profile received, standby 


Downlink Messages 


PRO: Profile proposal 

RT phraseology : “Request to cruise at Mach .mm and descend at (Mach .mm,) kkk knots indicated” 
CTAS: ccccc#hhmmss#xxx#yyy#m.mm#m.mm#kkk#nn#in 

GOLDN 170515 234.34 456.20 .72 .72 295 0764 58 
TRX: PRO:ccccc:HHMMSS:NXXXXXXXWXXXXXXX:.MM:.MM:KKK:RRRR 

PRO: GOLDN:170515:N0404507W1024915:.72:.72:295:0764 

PAS: N.A. 

INF: Information message 

RT phraseology: any non-standard informative message 
CTAS: cc (up to 202 characters) 

TRX: INFrcc (up to 202 char.) 

PAS: N.A. 

This is an info message 
INF:This is an info message 

ROG: Roger 

RT phraseology: “roger” 

CTAS: nnnnnn 

TRX: ROG:NNNNNN 

PAS: nnnnnn 

123456 
ROG: 123456 
123456 

UNA: Unable 

RT phraseology : 

CTAS: nnnnnn 

TRX: UNA:NNNNNN 

PAS: nnnnnn 

170623 
UNA: 170623 
170623 
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